Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Replace Report_AddComment with AddComment (Part 2) #9350

Merged
merged 21 commits into from
Jul 5, 2022

Conversation

marcaaron
Copy link
Contributor

@marcaaron marcaaron commented Jun 8, 2022

Details

This PR:

  • Remove the reportComment Pusher subscriptions (updateReportWithNewAction() remains and is used in the Urban Airship notification as I'm not sure how we are handling "onyx updates" there yet)
  • Updates DeprecatedAPI.Report_AddComment() to API.write('AddComment')

To minimize changes I decided to keep the "attachment" and "comment" flows together for now.

Test in connection with: https://github.com/Expensify/Web-Expensify/pull/33951

Fixed Issues (Related to

https://github.com/Expensify/Expensify/issues/211241

Tests

Same as QA but with an additional test to verify that users blocked by Concierge will see an error message inline.

Test Blocked from Concierge

  1. Log in with a test user account
  2. Begin chatting with Concierge
  3. Sign into OldDot with your local expensify.com account
  4. Block the test user via Concierge
    2022-06-23_08-29-17
  5. Send a message from the user account to Concierge DM
  6. Verify an inline message appears and the chat composer is disabled

2022-06-23_08-29-56

QA Steps

Testing a report comment is sent in realtime

  1. Create two accounts and a chat between them. Open a new NewDot window in a new Chrome session (do not use incognito mode).
  2. Send messages back and forth from each account to the other in a DM chat
  3. Verify they appear in realtime

Testing a report comment browser notification appears when the chat is not active (web)

  1. Create two accounts and a chat between them. Open a new NewDot window in a new Chrome session (do not use incognito mode).
  2. Send message from Account A to Account B while Account B is focused on another chat
  3. Verify a browser notification appears for Account B

Testing a report comment is queued while offline and sent when online again

  1. Create two accounts and a chat between them. Open a new NewDot window in a new Chrome session (do not use incognito mode).
  2. Send message from Account A to Account B while Account A is "offline"
  3. Verify Account A sees the message in a grey "pending" state
  4. Bring Account A back online
  5. Verify the message darkens to indicate it was created.
  6. Verify Account B can also see the message now

Add an attachment

  1. Create two accounts and a chat between them. Open a new NewDot window in a new Chrome session (do not use incognito mode).
  2. Add an attachment to the chat between these two users.
  3. Verify the attachment appears in realtime for the other user (Note: it may take some time for it to upload - this is normal).

Add an attachment (offline)

  1. Create two accounts and a chat between them. Open a new NewDot window in a new Chrome session (do not use incognito mode).
  2. Add an attachment to the chat between these two users while offline.
  3. Verify the attachment appears greyed to indicate that it is pending.
  4. Bring the user online.
  5. Verify the attachment darkens to indicate it is created
  6. Verify the attachment appears in realtime for the other user

Add attachment with text

  1. Create two accounts and a chat between them. Open a new NewDot window in a new Chrome session (do not use incognito mode).
  2. Add an attachment to the chat between these two users while there is text in the composer.
  3. Verify the attachment and text appears in realtime for the other user.
  • Verify that no errors appear in the JS console

PR Review Checklist

Contributor (PR Author) Checklist

  • I linked the correct issue in the ### Fixed Issues section above
  • I wrote clear testing steps that cover the changes made in this PR
    • I added steps for local testing in the Tests section
    • I added steps for Staging and/or Production testing in the QA steps section
    • I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
    • I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
  • I included screenshots or videos for tests on all platforms
  • I ran the tests on all platforms & verified they passed on:
    • iOS / native
    • Android / native
    • iOS / Safari
    • Android / Chrome
    • MacOS / Chrome
    • MacOS / Desktop
  • I verified there are no console errors (if there’s a console error not related to the PR, report it or open an issue for it to be fixed)
  • I followed proper code patterns (see Reviewing the code)
    • I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick)
    • I verified that comments were added to code that is not self explanatory
    • I verified that any new or modified comments were clear, correct English, and explained “why” the code was doing something instead of only explaining “what” the code was doing.
    • I verified any copy / text shown in the product was added in all src/languages/* files
    • I verified any copy / text that was added to the app is correct English and approved by marketing by tagging the marketing team on the original GH to get the correct copy.
    • I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named “index.js”. All platform-specific files are named for the platform the code supports as outlined in the README.
    • I verified the JSDocs style guidelines (in STYLE.md) were followed
  • If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
  • I followed the guidelines as stated in the Review Guidelines
  • I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
  • I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
  • I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
  • If a new component is created I verified that:
    • A similar component doesn't exist in the codebase
    • All props are defined accurately and each prop has a /** comment above it */
    • Any functional components have the displayName property
    • The file is named correctly
    • The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
    • The only data being stored in the state is data necessary for rendering and nothing else
    • For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
    • Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
    • All JSX used for rendering exists in the render method
    • The component has the minimum amount of code necessary for its purpose and it is
  • If a new CSS style is added I verified that:
    • A similar style doesn’t already exist
    • The style can’t be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(themeColors.componentBG)
  • If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
  • If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.

PR Reviewer Checklist

  • I verified the correct issue is linked in the ### Fixed Issues section above
  • I verified testing steps are clear and they cover the changes made in this PR
    • I verified the steps for local testing are in the Tests section
    • I verified the steps for Staging and/or Production testing are in the QA steps section
    • I verified the steps cover any possible failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
    • I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
  • I checked that screenshots or videos are included for tests on all platforms
  • I verified tests pass on all platforms & I tested again on:
    • iOS / native
    • Android / native
    • iOS / Safari
    • Android / Chrome
    • MacOS / Chrome
    • MacOS / Desktop
  • I verified there are no console errors (if there’s a console error not related to the PR, report it or open an issue for it to be fixed)
  • I verified proper code patterns were followed (see Reviewing the code)
    • I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick).
    • I verified that comments were added to code that is not self explanatory
    • I verified that any new or modified comments were clear, correct English, and explained “why” the code was doing something instead of only explaining “what” the code was doing.
    • I verified any copy / text shown in the product was added in all src/languages/* files
    • I verified any copy / text that was added to the app is correct English and approved by marketing by tagging the marketing team on the original GH to get the correct copy.
    • I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named “index.js”. All platform-specific files are named for the platform the code supports as outlined in the README.
    • I verified the JSDocs style guidelines (in STYLE.md) were followed
  • If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
  • I verified that this PR follows the guidelines as stated in the Review Guidelines
  • I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
  • I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
  • If a new component is created I verified that:
    • A similar component doesn't exist in the codebase
    • All props are defined accurately and each prop has a /** comment above it */
    • Any functional components have the displayName property
    • The file is named correctly
    • The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
    • The only data being stored in the state is data necessary for rendering and nothing else
    • For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
    • Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
    • All JSX used for rendering exists in the render method
    • The component has the minimum amount of code necessary for its purpose and it is broken down into smaller components in order to separate concerns and functions
  • If a new CSS style is added I verified that:
    • A similar style doesn’t already exist
    • The style can’t be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(themeColors.componentBG)
  • If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
  • If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.

Screenshots

Web

2022-06-23_08-36-00

Mobile Web

2022-07-05_06-56-53

Desktop

2022-07-05_07-01-39

iOS

2022-07-05_06-47-18
2022-07-05_06-50-42

Android

2022-07-05_07-39-42

@marcaaron marcaaron self-assigned this Jun 8, 2022
Copy link
Contributor

@Luke9389 Luke9389 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Beautiful. Just nabs and clarifying questions

src/components/InlineSystemMessage.js Show resolved Hide resolved
src/libs/actions/Report.js Outdated Show resolved Hide resolved
src/libs/actions/Report.js Show resolved Hide resolved
@marcaaron marcaaron changed the title [HOLD] [WIP] Replace Report_AddComment with AddComment (Part 2) [HOLD] Replace Report_AddComment with AddComment (Part 2) Jun 15, 2022
@marcaaron marcaaron changed the title [HOLD] Replace Report_AddComment with AddComment (Part 2) [HOLD] Replace Report_AddComment with CreateComment (Part 2) Jun 15, 2022
@marcaaron marcaaron marked this pull request as ready for review June 15, 2022 20:53
@marcaaron marcaaron requested a review from a team as a code owner June 15, 2022 20:53
@marcaaron marcaaron changed the title [HOLD] Replace Report_AddComment with CreateComment (Part 2) [HOLD Web-E 33951] Replace Report_AddComment with CreateComment (Part 2) Jun 15, 2022
@melvin-bot melvin-bot bot requested review from arosiclair and removed request for a team June 15, 2022 20:54
@marcaaron
Copy link
Contributor Author

This is still on HOLD, but I think ready for some reviews.

@marcaaron marcaaron requested a review from yuwenmemon June 15, 2022 20:54
@marcaaron marcaaron changed the title Replace Report_AddComment with CreateComment (Part 2) Replace Report_AddComment with AddComment (Part 2) Jun 23, 2022
@marcaaron marcaaron changed the title Replace Report_AddComment with AddComment (Part 2) [HOLD] Replace Report_AddComment with AddComment (Part 2) Jun 27, 2022
@marcaaron
Copy link
Contributor Author

Putting a HOLD on this one while we work out some things in https://github.com/Expensify/Web-Expensify/pull/34086

@marcaaron
Copy link
Contributor Author

This is still on hold pending the deploy of https://github.com/Expensify/Web-Expensify/pull/34086

However, we will need to merge this relatively quickly one that code hits production so I think we should start getting some reviews in.

@marcaaron marcaaron changed the title [HOLD] Replace Report_AddComment with AddComment (Part 2) Replace Report_AddComment with AddComment (Part 2) Jul 5, 2022
@marcaaron
Copy link
Contributor Author

Taking this off hold as the linked Web-Expensify PR is on staging.

@marcaaron
Copy link
Contributor Author

We should only merge this when it's on production though.

@marcaaron
Copy link
Contributor Author

Testing well for me on all platforms.

@marcaaron
Copy link
Contributor Author

Just a reminder, this very urgently needs to be merged and deployed as soon as the Web-Expensify PR goes to prod. For that reason I am also CP-ing to staging.

@github-actions
Copy link
Contributor

github-actions bot commented Jul 5, 2022

⚠️ ⚠️ Heads up! This pull request has the CP Staging label. ⚠️ ⚠️
Merging it will cause it to be immediately deployed to staging, even if the open StagingDeployCash deploy checklist is locked.

Copy link
Contributor

@yuwenmemon yuwenmemon left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM! 🎉

Copy link
Contributor

@arosiclair arosiclair left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks solid 👍🏽

Copy link
Contributor

@PauloGasparSv PauloGasparSv left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!
Merging it already since it has to go fast

@PauloGasparSv PauloGasparSv merged commit 258c268 into main Jul 5, 2022
@PauloGasparSv PauloGasparSv deleted the marcaaron-updateReportWithNewAction2 branch July 5, 2022 21:17
OSBotify pushed a commit that referenced this pull request Jul 5, 2022
…Action2

Replace Report_AddComment with AddComment (Part 2)

(cherry picked from commit 258c268)
OSBotify added a commit that referenced this pull request Jul 5, 2022
Comment on lines +143 to +146
function canUpdateTimezone() {
return lastUpdatedTimezoneTime.isBefore(moment().subtract(5, 'minutes'));
}

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I know this is just a refactor but why do we try to update every 5 minutes? feels like way too often, it probably only matters when a user is traveling but even then I don't really need my timezone updated every step of the way, just like when I arrive to my destination.

actually thinking about this more (i know this is all one comment but time passed between the first paragraph and this one)... why put a time limit on it at all? why not just check if the current timezone is different than the one in onyx and only attempt to set it if they are different?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That could work. I'm not sure why we chose every 5 minutes or whether it would be easier to check if the timezone has changed. I think there is some kind of cost associated with trying to "guess" the timezone and maybe that's why this is throttled, but not really focused on improving this particular feature.

DateUtils.setTimezoneUpdated();
}

API.write(isAttachment ? 'AddAttachment' : 'AddComment', parameters, {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think here I might have preferred a separate variable like

const command = isAttachment ? 'AddAttachment' : 'AddComment';
API.write(command, parameters, ...);

or maybe even getting rid of isAttachment and renaming that command at the top of the method and instead forking logic if command is AddAttachment or AddComment though that might end up being way too verbose 🤷

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

eh i guess looking back we use isAttachment inside of the onxyData and a few other places so maybe this is the best route the way it's written.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Don't really have strong feelings one way or the other on this.

@@ -69,7 +69,7 @@ describe('actions/Report', () => {
// the comment we left and it will be in a loading state because
// it's an "optimistic comment"
expect(action.message[0].text).toBe('Hello!');
expect(action.loading).toBe(true);
expect(action.isPending).toBe(true);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

shouldn't this be isLoading?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes good catch.

@kavimuru
Copy link

kavimuru commented Jul 7, 2022

@marcaaron We never get notification in mweb.
Section 2:

  1. Testing a report comment browser notification appears when the chat is not active (web)
  2. Create two accounts and a chat between them. Open a new NewDot window in a new Chrome session (do not use incognito mode).
  3. Send message from Account A to Account B while Account B is focused on another chat
  4. Verify a browser notification appears for Account B

So step 4, No notification received in mWeb environment.

@roryabraham
Copy link
Contributor

We never get notification in mweb

Correct me if I'm wrong @marcaaron, but I believe that's expected and maybe depends on the device/browser. I'm an iOS user and never get notifications from mobile websites like I do on my laptop.

@marcaaron
Copy link
Contributor Author

Yeah, I have never seen a mobile web browser notification ever.

@yuwenmemon
Copy link
Contributor

Yeah @kavimuru that isn't a blocker 👍

@OSBotify
Copy link
Contributor

OSBotify commented Jul 8, 2022

🚀 Deployed to production by @roryabraham in version: 1.1.79-17 🚀

platform result
🤖 android 🤖 failure ❌
🖥 desktop 🖥 success ✅
🍎 iOS 🍎 success ✅
🕸 web 🕸 success ✅

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants